Skip to content

Conversation

@roomote
Copy link
Contributor

@roomote roomote bot commented Aug 22, 2025

Description

This PR attempts to address Issue #7322 where the Chutes AI API returns an unexpected error: "The language model did not provide any assistant messages."

Problem

When using Chutes AI (either with the built-in provider or via OpenAI compatible API), the API sometimes returns responses without any content in the stream chunks, causing the application to throw an error about missing assistant messages.

Solution

  • Added content tracking (hasContent flag) in the ChutesHandler.createMessage() method
  • Implemented validation for both DeepSeek R1 and non-DeepSeek models
  • Throws a descriptive error when the API returns no content
  • The error message helps users understand the issue may be with the API, model configuration, or request parameters

Changes

  • Modified src/api/providers/chutes.ts to track and validate content presence
  • Added comprehensive test coverage in src/api/providers/__tests__/chutes.spec.ts
  • Updated existing tests to avoid triggering the new validation

Testing

  • ✅ All existing tests pass
  • ✅ New tests added for empty response scenarios
  • ✅ Tests cover both DeepSeek R1 and standard models

Fixes #7322

Feedback and guidance are welcome!


Important

Adds content tracking and validation in ChutesHandler to handle empty responses from Chutes AI API, with tests for both DeepSeek R1 and standard models.

  • Behavior:
    • Adds hasContent flag in ChutesHandler.createMessage() to track content presence.
    • Throws error if no content is returned by the API, with a descriptive message.
    • Handles both DeepSeek R1 and non-DeepSeek models.
  • Testing:
    • Adds tests in chutes.spec.ts for empty response scenarios.
    • Tests ensure errors are thrown for both DeepSeek R1 and standard models when no content is returned.
  • Files:
    • Modifies chutes.ts to implement content tracking and validation.
    • Updates chutes.spec.ts to include new test cases for empty responses.

This description was created by Ellipsis for 62b49a1. You can customize this summary. It will automatically update as commits are pushed.

- Add content tracking in ChutesHandler.createMessage() for both DeepSeek and non-DeepSeek models
- Throw descriptive error when API returns no content
- Add test coverage for empty response scenarios
- Fixes #7322
@roomote roomote bot requested review from cte, jr and mrubens as code owners August 22, 2025 16:02
@dosubot dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. bug Something isn't working labels Aug 22, 2025
// If no content was received, throw an error
if (!hasContent) {
throw new Error(
`${this.providerName} API did not return any content. This may indicate an issue with the API, model configuration, or request parameters.`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicate error message text appears in both branches. Consider extracting the error string into a shared constant to reduce duplication and ease future maintenance.

Copy link
Contributor Author

@roomote roomote bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

}

// If no content was received, throw an error
if (!hasContent) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notice both branches have identical error handling logic. Could we extract this into a shared helper method to follow DRY principles? Something like:

private throwIfNoContent(hasContent: boolean): void {
  if (!hasContent) {
    throw new Error(
      `${this.providerName} API did not return any content. This may indicate an issue with the API, model configuration, or request parameters.`,
    )
  }
}

} else {
yield* super.createMessage(systemPrompt, messages)
// For non-DeepSeek models, we reimplement the stream handling instead of calling
// super.createMessage() to ensure consistent error handling for empty responses
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a specific reason we're reimplementing the stream handling instead of wrapping the parent's implementation? We could potentially do something like:

const parentStream = super.createMessage(systemPrompt, messages);
let hasContent = false;
for await (const chunk of parentStream) {
  if (chunk.type === 'text') hasContent = true;
  yield chunk;
}
if (!hasContent) throw new Error(...);

This would reduce code duplication and maintenance burden.

// If no content was received, throw an error
if (!hasContent) {
throw new Error(
`${this.providerName} API did not return any content. This may indicate an issue with the API, model configuration, or request parameters.`,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we make the error message more actionable? For example: "Check your API key validity, model availability, or request parameters (e.g., max_tokens, temperature)."

[Symbol.asyncIterator]: async function* () {
// Empty stream for this test
// Yield minimal content to avoid triggering the empty response error
yield {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be cleaner to keep the original test unchanged and create a separate test specifically for the empty stream scenario? This modification makes the test less clear about its original intent.

async next() {
if (!called) {
called = true
// Return minimal content to avoid triggering the empty response error
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same concern here - this test modification obscures the original test intent. Consider keeping the original test and adding a new one for the empty response case.

@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Aug 22, 2025
@daniel-lxs daniel-lxs moved this from Triage to PR [Needs Prelim Review] in Roo Code Roadmap Aug 23, 2025
@hannesrudolph hannesrudolph added PR - Needs Preliminary Review and removed Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. labels Aug 23, 2025
@daniel-lxs
Copy link
Member

Issue needs info

@daniel-lxs daniel-lxs closed this Aug 25, 2025
@github-project-automation github-project-automation bot moved this from New to Done in Roo Code Roadmap Aug 25, 2025
@github-project-automation github-project-automation bot moved this from PR [Needs Prelim Review] to Done in Roo Code Roadmap Aug 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working PR - Needs Preliminary Review size:L This PR changes 100-499 lines, ignoring generated files.

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

Unexpected API response Problem with Chutes AI

4 participants